grouping of web apps into processes
configuration of HTTP worker process identity
separation of web apps into different worker processes for security and fault tolerance
all of the above

clients will use Kerberos to authenticate with the web server
clients must use Internet Explorer
ASP.NET will use whatever client identity IIS discovered during authentication
This web.config setting simply says "let IIS do the work of figuring out who the client is". This doesn't mean we'll always use Kerberos - it depends on the authentication settings you've chosen in IIS - you could very well have chosen to allow anonymous access, for example. Or Basic authentication.

are a good place to implement mandatory security features
should never be used for security code, because web page developers might forget to call them
The ASP.NET plumbing ensures that modules get called, which is the beauty of using them to implement security features.

is based on the >authorization< section in web.config
doesn't have any effect on static files if they are served up directly by the kernel, so watch out!
does not require the client to have a Windows account
allows both role based checks and direct tests for user names
all of the above

is encrypted by default so we never worry about it getting stolen by a bad guy
is MAC protected by default so the client cannot change her name in the cookie in an attempt to elevate her privileges
must be present if forms authentication is in use, otherwise the user will be redirected to a login page
If the entire cookie is stolen, it can be replayed. Just because the cookie itself is encrypted doesn't mean it can't be replayed to steal a logon. Steal the cookie, steal the logon, remember that! Also, keep in mind that forms authentication doesn't say who is allowed to view pages; this is controlled by the <authorization> section, so it's totally possible that someone without a forms cookie (an unauthenticated user, in other words) could happily browse parts of your website, if that's what you want to allow.